<html>
<head><meta charset="utf-8"><title>Raw pointer validity requirements · t-lang/wg-unsafe-code-guidelines · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/index.html">t-lang/wg-unsafe-code-guidelines</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html">Raw pointer validity requirements</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="229223295"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229223295" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> eaglgenes101 <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229223295">(Mar 07 2021 at 22:32)</a>:</h4>
<p>So my current understanding of stacked borrows' requirements on raw pointers to be valid is that the the provenance of the reference that they came from must be continuously valid from their creation from that reference to the time that they are accessed. This is why we have the problem with soundness of intrusive data structures, as described in <a href="https://gist.github.com/Darksonn/1567538f56af1a8038ecc3c664a42462">https://gist.github.com/Darksonn/1567538f56af1a8038ecc3c664a42462</a> . </p>
<p>In that, the raw pointer in one node is invalidated because the provenance of the original reference it came from is conflicted by the mutable access from the other node.  This is despite the mutable reference in question being long gone by the time the other node is mutably accessed. </p>
<p>Is my understanding correct? And is there a reason that the memory access rules around raw pointers are as strict as they are?</p>



<a name="229224029"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229224029" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229224029">(Mar 07 2021 at 22:45)</a>:</h4>
<p>You only need a mutable reference to exist for a short time for it to write to memory. It doesn't matter if the mut reference is gone if the damage is done</p>



<a name="229224584"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229224584" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> eaglgenes101 <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229224584">(Mar 07 2021 at 22:54)</a>:</h4>
<p><span class="user-mention silent" data-user-id="271719">Mario Carneiro</span> <a href="#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements/near/229224029">said</a>:</p>
<blockquote>
<p>You only need a mutable reference to exist for a short time for it to write to memory. It doesn't matter if the mut reference is gone if the damage is done</p>
</blockquote>
<p>But there is never a point where there actually are two mutable references pointing to the same place, nor is there ever a point where the raw pointer is written to while a mutable reference is live. So _what_ is being invalidated here, besides the long-dead corpse of a mutable reference?</p>



<a name="229224969"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229224969" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229224969">(Mar 07 2021 at 23:00)</a>:</h4>
<p>If pointer <code>*const T</code> is derived from a <code>&amp;T</code> then when it is later used that <code>&amp;T</code> should still be valid, in the dynamic (not compile time checked) sense. So in particular the data at that address should still exist and should still be a <code>T</code>, and should still have the same value as it did when the pointer was created (modulo interior mutability). Now when some <code>*mut U</code> comes along to overlap those bytes, that's okay unless you either write to the pointer or turn it into a <code>&amp;mut U</code>, because now <code>T</code> is potentially compromised - who knows what you would see if you tried to read a <code>T</code> after this point. You can drop the pointer but it doesn't matter, the original <code>*const T</code> is invalid.</p>



<a name="229225206"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229225206" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229225206">(Mar 07 2021 at 23:04)</a>:</h4>
<p>By the way, in case you missed it, there was a recent UCG discussion about intrusive collections here: <a href="https://github.com/rust-lang/unsafe-code-guidelines/issues/272">https://github.com/rust-lang/unsafe-code-guidelines/issues/272</a></p>



<a name="229225778"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229225778" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229225778">(Mar 07 2021 at 23:13)</a>:</h4>
<p>In particular, the solution I suggest in that thread is to use a guard as an extra layer of indirection. This is roughly analogous to the "boxing" approach mentioned in the gist, but it doesn't actually require heap allocation, it can be done entirely on the stack. I don't know whether that suffices for your use cases.</p>



<a name="229225782"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229225782" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> eaglgenes101 <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229225782">(Mar 07 2021 at 23:13)</a>:</h4>
<p>Okay, understood, at least as far as the abstract machine model rules apply. </p>
<p>I'm currently looking for the justification for _why_ the stacked borrows model was designed this way.</p>



<a name="229225879"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229225879" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229225879">(Mar 07 2021 at 23:15)</a>:</h4>
<p>This is to allow for inter-procedural optimizations, where you can make strong claims about what foreign code can do to invalidate data you have a pointer to</p>



<a name="229225984"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229225984" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> eaglgenes101 <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229225984">(Mar 07 2021 at 23:17)</a>:</h4>
<p>And this sort of thing isn't already provided for by references, which pointers can be cast to?</p>



<a name="229226084"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229226084" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229226084">(Mar 07 2021 at 23:18)</a>:</h4>
<p>In the intrusive collection situation, it <em>is</em> references causing the problem</p>



<a name="229226110"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229226110" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229226110">(Mar 07 2021 at 23:19)</a>:</h4>
<p>or more specifically, the root bindings that you have to values on the stack</p>



<a name="229226321"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229226321" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> eaglgenes101 <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229226321">(Mar 07 2021 at 23:22)</a>:</h4>
<p>Okay, so the references are causing problems to the validity of pointers? Am I understanding right?</p>



<a name="229226359"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229226359" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229226359">(Mar 07 2021 at 23:23)</a>:</h4>
<p>right, any &amp;mut invalidates any *mut or *const pointer pointing at that data</p>



<a name="229226448"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229226448" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> eaglgenes101 <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229226448">(Mar 07 2021 at 23:25)</a>:</h4>
<p>For just the lifetime that the reference is live? Or afterwards as well? It's the latter case that I think is overly strict.</p>



<a name="229226475"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229226475" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> comex <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229226475">(Mar 07 2021 at 23:25)</a>:</h4>
<p>So imagine that you later did <code>pair_2.value = 123</code> (or whatever you need to do to accomplish that with Pin).  We want the compiler to be able to assume that <code>main</code> has unique access to <code>pair_2</code>, since the last time it was mutably borrowed.</p>



<a name="229226494"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229226494" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> comex <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229226494">(Mar 07 2021 at 23:26)</a>:</h4>
<p>which in this case would be <code>pair_2.as_mut()</code> when it's passed to <code>link_up</code></p>



<a name="229226554"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229226554" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> comex <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229226554">(Mar 07 2021 at 23:26)</a>:</h4>
<p>Because the compiler can assume that nobody else is accessing <code>pair_2</code> in that whole span, it could theoretically move that write to <code>value</code> upward, past <code>pair_1.get_value</code>.</p>



<a name="229226684"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229226684" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> comex <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229226684">(Mar 07 2021 at 23:28)</a>:</h4>
<p>Now, we don't actually have such an optimization.  All we have is <code>noalias</code> which isn't even enabled, but if it were enabled, it would only assume unique access if you were in a function that took a mutable reference to <code>pair_2</code> as a function parameter.</p>



<a name="229226715"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229226715" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> comex <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229226715">(Mar 07 2021 at 23:29)</a>:</h4>
<p>In other words, I think it would be compatible with your hypothetical "invalidates only for lifetime that reference is alive" rule.</p>



<a name="229226822"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229226822" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> comex <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229226822">(Mar 07 2021 at 23:30)</a>:</h4>
<p>But that's basically because LLVM was written as a C backend, and <code>noalias</code> is meant to reflect C <code>restrict</code>.  In theory we may want to have more aggressive optimizations in the future.</p>



<a name="229226924"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229226924" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> comex <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229226924">(Mar 07 2021 at 23:32)</a>:</h4>
<p><span class="user-mention" data-user-id="120791">@RalfJ</span> might have better examples of why this would be useful.</p>



<a name="229227483"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229227483" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229227483">(Mar 07 2021 at 23:40)</a>:</h4>
<p>Here's a modification to the example from the gist to use a guard, that passes miri: <a href="https://play.rust-lang.org/?version=stable&amp;mode=debug&amp;edition=2018&amp;gist=ada9e739a7c1448c0a08e9ce024fd2bb">https://play.rust-lang.org/?version=stable&amp;mode=debug&amp;edition=2018&amp;gist=ada9e739a7c1448c0a08e9ce024fd2bb</a></p>



<a name="229227638"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229227638" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> comex <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229227638">(Mar 07 2021 at 23:43)</a>:</h4>
<p>I'm not sure that actually works… you still have mutable borrows, so the only reason that works is that it's not really a cyclic data structure.</p>



<a name="229227640"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229227640" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229227640">(Mar 07 2021 at 23:43)</a>:</h4>
<p>Actually the <code>link_up</code> function should be unsafe, since the API doesn't prevent you from calling it with two of the same guard. The <code>get_value</code> function can probably be safe, as long as <code>Guard</code> is not Send or Sync</p>



<a name="229227704"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229227704" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> comex <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229227704">(Mar 07 2021 at 23:44)</a>:</h4>
<p>Well, it's a bit odd because the original <code>Pair</code> example is also not a cyclic data structure.</p>



<a name="229227705"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229227705" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> eaglgenes101 <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229227705">(Mar 07 2021 at 23:44)</a>:</h4>
<p>I would think that trying to do this kind of code motion is already broken by a much more pedestreian case: </p>
<p><a href="https://play.rust-lang.org/?version=stable&amp;mode=debug&amp;edition=2018&amp;gist=9d4f09620b3c3a4fc64a4d03fa6cc31a">https://play.rust-lang.org/?version=stable&amp;mode=debug&amp;edition=2018&amp;gist=9d4f09620b3c3a4fc64a4d03fa6cc31a</a></p>
<p>You can't move the <code>set</code> above the <code>get</code> without making the assert fail.</p>



<a name="229227708"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229227708" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229227708">(Mar 07 2021 at 23:44)</a>:</h4>
<p>It should work with arbitrary links. The reason it works is because the mutable borrows are all disjoint in time, like in a RefCell</p>



<a name="229227789"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229227789" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> comex <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229227789">(Mar 07 2021 at 23:45)</a>:</h4>
<p><span class="user-mention" data-user-id="202599">@eaglgenes101</span> In that case, <code>Rc</code> hands out immutable references, which normally /would/ be subject to assumptions, namely the assumption that the referent can't change at all.  But there's an exception for <code>UnsafeCell</code>, which <code>Cell</code> uses internally.</p>



<a name="229227790"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229227790" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229227790">(Mar 07 2021 at 23:46)</a>:</h4>
<p>and in particular, every node is pinned exactly once, for its entire lifetime, and the mutable reference is used to spawn a guard pointer, which is then copied around arbitrarily, and later turned back into a mutable reference (one at a time) in arbitrary order</p>



<a name="229227850"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229227850" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> comex <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229227850">(Mar 07 2021 at 23:46)</a>:</h4>
<p><span class="user-mention" data-user-id="202599">@eaglgenes101</span> But without <code>&amp;mut</code> references, there's no uniqueness assumption.</p>



<a name="229227860"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229227860" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> comex <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229227860">(Mar 07 2021 at 23:46)</a>:</h4>
<p><span class="user-mention" data-user-id="271719">@Mario Carneiro</span> Oh, sure, if you only ever need to access each pair once.</p>



<a name="229227917"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229227917" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> comex <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229227917">(Mar 07 2021 at 23:47)</a>:</h4>
<p><span class="user-mention" data-user-id="271719">@Mario Carneiro</span> But for a realistic use case you would have something like <code>struct Pair { prev: *mut Pair, next: *mut Pair, value: u64 }</code>.  And you cannot ever mutably borrow <code>Pair</code> without invalidating anything else that points to it.</p>



<a name="229227989"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229227989" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229227989">(Mar 07 2021 at 23:48)</a>:</h4>
<p>hold on, let me make a cycle in the example</p>



<a name="229228238"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229228238" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> comex <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229228238">(Mar 07 2021 at 23:52)</a>:</h4>
<p>Well, I was wrong that you can't have mutable borrows at all.  You can, as long as you don't use them to derive the pointers stored in the links.</p>



<a name="229229006"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229229006" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229229006">(Mar 08 2021 at 00:03)</a>:</h4>
<p>Here's a more interesting version: <a href="https://play.rust-lang.org/?version=stable&amp;mode=debug&amp;edition=2018&amp;gist=37a92d802d1fc60d5683094ed9eba67c">https://play.rust-lang.org/?version=stable&amp;mode=debug&amp;edition=2018&amp;gist=37a92d802d1fc60d5683094ed9eba67c</a></p>



<a name="229230411"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229230411" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229230411">(Mar 08 2021 at 00:23)</a>:</h4>
<p>The way I think of it is that each mutable reference points to its data:</p>
<div class="codehilite"><pre><span></span><code>m1 --&gt; v1
m2 --&gt; v2
m3 --&gt; v3
</code></pre></div>
<p>Here <code>v1</code> is the <code>Node</code> and <code>m1</code> is a <code>&amp;mut Node</code>. Now we create <code>g1</code>, a <code>*mut Node</code> derived from <code>m1</code>, and similarly for the others. <code>g1</code> owns nothing, it's really just a number that we can use to access <code>m1</code> when we need to do anything on the node <code>v1</code>. So we can copy it around like so:</p>
<div class="codehilite"><pre><span></span><code>g1 = m1 --&gt; v1(g2)
g2 = m2 --&gt; v2(g3)
g3 = m3 --&gt; v3(g1)
</code></pre></div>
<p>Here I'm putting <code>g1</code> in node <code>v3</code> by just copying it in. Note that the graph of derived references is still acyclic. When we want to access one of these nodes, we put say <code>g2</code> on the local stack, and deref it to get <code>m2</code>. This invalidates any other references derived from <code>m2</code> or <code>v2</code>, but luckily there aren't any; we have <code>g2</code> stored in <code>v1</code> but that's just a pointer derived from <code>m2</code>, which we're currently using and is still valid. We can make our changes and end the reborrow of <code>m2</code>, or we can borrow multiple nodes at once if we want to (taking care not to borrow the same node twice), and nothing will be invalidated. Finally, at the end of scope we finally let the borrows <code>m1,m2,m3</code> end, and then drop <code>v1,v2,v3</code>.</p>
<p>We don't need pinning here because we can't really do any damage by moving things (you can replace a node and its pointer but any incoming pointers will just point at the new data). Maybe a more complex data structure needs it, but I think these simple graphs or doubly linked lists don't.</p>



<a name="229231387"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229231387" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thales Fragoso <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229231387">(Mar 08 2021 at 00:38)</a>:</h4>
<p>A &amp;T doesn't invalidate a *mut T, right ?</p>



<a name="229233998"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229233998" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229233998">(Mar 08 2021 at 01:19)</a>:</h4>
<p>right</p>



<a name="229411445"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229411445" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> eaglgenes101 <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229411445">(Mar 09 2021 at 02:26)</a>:</h4>
<p>So what I'm getting here is that some kind of wrapper that punches a hole in the pointer provenance rules would resolve the problem just as well as an <code>AliasMut</code> hole-punch in the mutable aliasing rules. </p>
<p>I'm still not convinced that the  potential optimization opportunities are sufficiently justifying of the strict pointer rules, especially since <code>UnsafeCell</code> is much more common in concurrency code and also inhibits similar aggressive optimizations. But you do you.</p>



<a name="229428414"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229428414" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229428414">(Mar 09 2021 at 06:25)</a>:</h4>
<p>I don't think it's possible to have any weaker rules on pointers than we already have, and in particular a wrapper type wouldn't help because you need both parties to collaborate for an allowable aliasing situation to work, and the wrapper type can only address one half of the picture. Any <code>&amp;mut T</code> needs to be unique and not aliasing with anything else, be they pointers or mut references or wrapper types trying to opt out of aliasing.</p>
<p>I'm still confused what situation actually requires such a wrapper type though; I thought the example was general enough to show how you can avoid needing any hole-punching at all.</p>



<a name="229464122"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229464122" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thales Fragoso <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229464122">(Mar 09 2021 at 11:52)</a>:</h4>
<p>Maybe futures generated through async ?</p>



<a name="229590336"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229590336" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> eaglgenes101 <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229590336">(Mar 10 2021 at 02:09)</a>:</h4>
<p><span class="user-mention silent" data-user-id="271719">Mario Carneiro</span> <a href="#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements/near/229428414">said</a>:</p>
<blockquote>
<p>I don't think it's possible to have any weaker rules on pointers than we already have, and in particular a wrapper type wouldn't help because you need both parties to collaborate for an allowable aliasing situation to work, and the wrapper type can only address one half of the picture. Any <code>&amp;mut T</code> needs to be unique and not aliasing with anything else, be they pointers or mut references or wrapper types trying to opt out of aliasing.</p>
<p>I'm still confused what situation actually requires such a wrapper type though; I thought the example was general enough to show how you can avoid needing any hole-punching at all.</p>
</blockquote>
<p>The wrappers I was thinking about would have the same function as the Guard type you created to solve the problem, but without the extra pointer indirection. Not strictly needed, but people are going to want the abstractions to be as zero-cost as reasonably possible.</p>



<a name="229664115"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/229664115" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#229664115">(Mar 10 2021 at 14:05)</a>:</h4>
<p>In the <a href="https://github.com/rust-lang/unsafe-code-guidelines/issues/272">UCG thread</a> I concluded that it's not possible in rust to have something like the Guard type without storing a pointer, because stack bindings are owned by the stack frame, so any use of a mutable reference to the guard is going to destroy all the pointers to the data.</p>
<p>However, I don't think the Guard type as written imposes an <em>extra</em> pointer indirection, because it is a Copy type, and passed by-value into all of the guard methods, so there's only one pointer involved in accessors, as opposed to the normal situation where the type has no internal references but gets passed by <code>&amp;self</code> or <code>&amp;mut self</code> so you have one pointer involved in accessors. If you tried to have zero pointers/references you would have to pass the node by value which is obviously not going to work since that moves the node, which destroys pointers to it (for real, not just some SB provenance destruction).</p>



<a name="230152471"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/230152471" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#230152471">(Mar 13 2021 at 10:01)</a>:</h4>
<p><span class="user-mention silent" data-user-id="202599">eaglgenes101</span> <a href="#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements/near/229224584">said</a>:</p>
<blockquote>
<p><span class="user-mention silent" data-user-id="271719">Mario Carneiro</span> <a href="#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements/near/229224029">said</a>:</p>
<blockquote>
<p>You only need a mutable reference to exist for a short time for it to write to memory. It doesn't matter if the mut reference is gone if the damage is done</p>
</blockquote>
<p>But there is never a point where there actually are two mutable references pointing to the same place, nor is there ever a point where the raw pointer is written to while a mutable reference is live. So _what_ is being invalidated here, besides the long-dead corpse of a mutable reference?</p>
</blockquote>
<p>think of pointers as forming a tree, with the children of a node being the ptrs "derived from" their parent. When you invalidate a node, you also kill all its children -- you prune that part of the tree. This is crucial to establish the following property (which in turn forms the basis of the strong aliasing-based optimizations we are shooting for):</p>
<p><em>When <code>x: &amp;mut T</code> is the topmost reference in the borrow stack, and I call some unknown function <code>f()</code>, and after that function returns <code>x</code> is still anywhere in the borrow stack, then the memory <code>x</code> points to was neither read nor written by the execution of <code>f()</code>.</em></p>
<p>The fact that borrows from a <em>stack</em> and that the use of references to a given memory location follows a well-nested structure is crucial here -- and if I understood correctly, that is what you are proposing to get rid of.</p>



<a name="230201954"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/230201954" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> eaglgenes101 <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#230201954">(Mar 14 2021 at 01:08)</a>:</h4>
<p><span class="user-mention silent" data-user-id="120791">RalfJ</span> <a href="#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements/near/230152471">said</a>:</p>
<blockquote>
<p>(which in turn forms the basis of the strong aliasing-based optimizations we are shooting for):</p>
</blockquote>
<p>My question is more _what_ strong aliasing-based optimizations are being envisioned here that aren't possible with slightly weaker rules like the ones I suggested, and what suggests that these optimizations will be effective in practice.</p>



<a name="230203277"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/230203277" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> eaglgenes101 <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#230203277">(Mar 14 2021 at 01:33)</a>:</h4>
<p>I guess the root of my issue is what role pointers play in the language. As I see it, references already exist for asserting dereferenceability and validity where they are present. So raw pointers don't need to be particularly strong, as when applicable, pointers can be casted to references (or some composition of references and wrapper types) to make the properties known to the optimizing compiler. The requirement for the dereferenced addresses to be valid is unavoidable, but besides that, pointers can be quite lax in what properties they actually guarantee, and exist largely to ease address manipulations and make these operations more visible to the compiler for optimization. </p>
<p>However, as you noted, the strength of the assertions that references can make doesn't entirely exist apart from pointers, and are influenced by what pointers can do.</p>



<a name="230228666"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/230228666" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#230228666">(Mar 14 2021 at 10:18)</a>:</h4>
<p><span class="user-mention silent" data-user-id="202599">eaglgenes101</span> <a href="#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements/near/230201954">said</a>:</p>
<blockquote>
<p>My question is more _what_ strong aliasing-based optimizations are being envisioned here that aren't possible with slightly weaker rules like the ones I suggested, and what suggests that these optimizations will be effective in practice.</p>
</blockquote>
<p>this paper goes into more details with concrete examples of optimizations and how to prove them using Stacked Borrows: <a href="http://plv.mpi-sws.org/rustbelt/stacked-borrows/">http://plv.mpi-sws.org/rustbelt/stacked-borrows/</a></p>



<a name="230228782"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/230228782" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#230228782">(Mar 14 2021 at 10:20)</a>:</h4>
<p>The goal is indeed to make raw pointers as weak as we can possibly make them (in terms of their invariants / requirements)</p>



<a name="230228807"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/230228807" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#230228807">(Mar 14 2021 at 10:20)</a>:</h4>
<p>every single restriction on raw pointers is motivated by being able to optimize references, i.e. if we removed the restriction, references could be optimized less. As <span class="user-mention" data-user-id="271719">@Mario Carneiro</span> said, when raw pointers and references alias, <em>both</em> need to be restricted to enable optimizations on the reference side. (to use some terminology from concurrency reasoning, references have a "rely"-style assumption on what happens with the pointee; <em>all</em> language operations must provide the corresponding "guarantee" to make this sound, including raw pointers. in other words, unrestricted raw pointers could mess up reference assumptions in arbitrary ways.)</p>



<a name="230228930"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/230228930" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#230228930">(Mar 14 2021 at 10:22)</a>:</h4>
<p>To make this discussion concrete it'd really help if you had a concrete self-contained piece of code (as small as possible) that is rejected by Stacked Borrows and that you think should be allowed. Then I can hopefully explain which reference-related optimization requires this restriction (or point to an existing open issue for known deficiencies of Stacked Borrows -- or open a new one)</p>



<a name="230263806"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/230263806" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> moxian <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#230263806">(Mar 14 2021 at 19:50)</a>:</h4>
<p>The first post of this thread mentions <a href="https://gist.github.com/Darksonn/1567538f56af1a8038ecc3c664a42462">https://gist.github.com/Darksonn/1567538f56af1a8038ecc3c664a42462</a> /  <a href="https://github.com/rust-lang/rust/issues/63818">https://github.com/rust-lang/rust/issues/63818</a>. So would I assume resolving that one is the primary motivation for the thread in the first place.</p>



<a name="230560529"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw%20pointer%20validity%20requirements/near/230560529" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/Raw.20pointer.20validity.20requirements.html#230560529">(Mar 16 2021 at 17:51)</a>:</h4>
<p>That won't be possible without language changes I am pretty sure; intrusive collections and self-referential generators do otherwise break under our optimizations</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>